home *** CD-ROM | disk | FTP | other *** search
- Path: mail2news.demon.co.uk!genesis.demon.co.uk
- From: Lawrence Kirby <fred@genesis.demon.co.uk>
- Newsgroups: comp.lang.c,comp.std.c
- Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
- Date: Mon, 29 Jan 96 23:37:46 GMT
- Organization: none
- Message-ID: <822958666snz@genesis.demon.co.uk>
- References: <30C40F77.53B5@swsbbs.com> <SPENCER.96Jan22113215@zorgon.ERA.COM> <KANZE.96Jan29121956@slsvewt.lts.sel.alcatel.de>
- Reply-To: fred@genesis.demon.co.uk
- X-NNTP-Posting-Host: genesis.demon.co.uk
- X-Newsreader: Demon Internet Simple News v1.27
- X-Mail2News-Path: genesis.demon.co.uk
-
- In article <KANZE.96Jan29121956@slsvewt.lts.sel.alcatel.de>
- kanze@lts.sel.alcatel.de "James Kanze US/ESC 60/3/141 #40763" writes:
-
- >I think the crux of Michael Furman's question lies therein. Does the
- >standard require a diagnostic if the function main is not of one of
- >the two types given?
-
- No, that is neither a syntax error (or at least need not be) or a violation
- of a rule in a constraints section so no diagnostic is required.
-
- >To tell the truth, I'm not sure what the answer is. The text
- >concerning main is in the chapter describing the environment. It
- >doesn't appear as a semantic restriction or anything. It simply
- >states that on start-up, a function called main will be called, and
- >that the implementation must support the following forms. It doesn't
- >seem (to me, at least) to say anything about what other forms it might
- >support, or what the implementation must do if given a fully other
- >definition of main.
-
- The standard defines the behaviour of 2 stated forms of main (and
- semantically equivalent forms). It doesn't define any behaviour for any
- other forms therefore those other forms result in undefined behaviour -
- from 3.16:
-
- "If a ``shall'' or ``shall not'' requirement that appears outside of
- a constraint is violated, the behaviour is undefined. Undefined behaviour
- is otherwise indicated by the words ``undefined behaviour'' or by the
- omission of any explicit definition of behaviour. There is no difference
- in emphasis among these three; they all describe ``behaviour that is
- undefined''".
-
- Other forms of main are an example of "omission of any explicit definition
- of behaviour" and by the last sentence have the same effect as any other
- form of undefined behaviour.
-
- >Normally, I would expect (at the very least) a compiler to generate a
- >warning or an error for a main that it did not support.
-
- There is no requirement for that. Indeed that allows useful implementation
- extensions without making the compiler non-conforming. Of course such
- extensions are non-portable.
-
- >In fact,
- >however, my compiler (gcc) accepts the following definition without
- >the slightest complaint, although I'd rather not think about what will
- >happen when I access parameter d:
- >
- > int main( char a , int b , long c , double d )
-
- main is something that the language leaves up to the programmer to get
- right.
-
- >|> For purposes of the C newsgroups, discussion of what is/isn't legal
- >|> is generally restricted to strictly conforming C.
- >
- >Yes and no. In comp.std.c, the discussion is exactly about what is
- >legal according to the standard. In comp.lang.c (to which this
- >article is also cross-posted), the discussion should generally be a
- >bit more open.
- >
- >Thus, for example, in comp.std.c, a program with a variable named far
- >is illegal, and that is it.
-
- I assume that was a typo (or thinko!) for "legal".
-
- >In comp.lang.c (and I hope in its
- >moderated variant), I would hope that someone would point out that,
- >legal or not, it's going to get you into trouble.
-
- Makes sense.
-
- --
- -----------------------------------------
- Lawrence Kirby | fred@genesis.demon.co.uk
- Wilts, England | 70734.126@compuserve.com
- -----------------------------------------
-